Typically, configurable-off-the-shelf (COTS) software refers to application software written for a variety of industries or users in a manner that permits the users to modify the program to meet individual requirements. The use of COTS software can reduce development effort by software developers and increase the timely development and delivery of products and services across various domains, such as engineering, medical, finance, travel, and so on.
Generally, simple forms of modification in COTS software may be addressed using configuration parameters with numeric or string typed values. However, in case a significant change is desired in the system, complex configuration values that are pieces of logic encapsulated in form of pseudo-code or high-level programming language may be utilized. Such complex configuration values offer unmatched flexibility to support a wide variety of customers with different requirements.
However, the use of complex configuration values that are pieces of logic makes it difficult for domain experts who are not programmers to configure the system for a given set of requirements. To the extent that different instantiations of the COTS software require identical or similar behavior, it becomes highly desirable to reuse configuration settings from previous configurations (e.g., those developed for similar customers in the past, or even for the same customer previously). Such reuse promises lower cost, faster turnaround, better quality, decrease in risk, simplified maintenance, and the potential for less stressful development and delivery processes.
However, while the reuse of configuration settings from previous configurations is highly desirable, it becomes difficult for even programmers to understand the behavior implemented by, and the relationship between, the different pieces of logic encapsulated in the various past configurations of application software. This problem is deepened by lack of COTS-specific software reuse models.
The above listed problems create several undesirable consequences, such as increase in cost due to involvement of expert programmers, high risk of loss in translation between domain experts who understand customers' requirements and programmers who must translate that into logic. Another consequence is the increased likelihood that programmers will use shortcuts to achieve the behavior needed, rather than reuse previously implemented configuration settings for a given parameter for the same or other customers, as it is often easier to write it from scratch. Over a period of time, these configuration values become opaque and very difficult to update, for example, in response to a change in legislation or customer requirements.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to a person having ordinary skill in the art, through a comparison of described systems with some aspects of the present disclosure, as set forth in the remainder of the present application and with reference to the drawings.